feat: drop PolicyProvider#701
Conversation
# Conflicts: # crates/l1/src/state/cache.rs # crates/l1/src/subscriber.rs # crates/l1/src/tests.rs # crates/node/README.md # crates/node/src/node.rs
| amount = %d.amount, | ||
| "Encrypted deposit recipient unauthorized; queuing deposit bounce-back" | ||
| ); | ||
| queued.rejected = true; |
There was a problem hiding this comment.
do we now never reject deposits? is it safe to just remove this logic?
There was a problem hiding this comment.
they are rejected at execution when the 403 logic runs
There was a problem hiding this comment.
basically it would be this code which calls mint() on the zone's TIP20:
- regular deposit:
zones/specs/ref-impls/src/zone/ZoneInbox.sol
Lines 236 to 245 in 95366b0
- encrypted deposit:
zones/specs/ref-impls/src/zone/ZoneInbox.sol
Lines 320 to 325 in 95366b0
There was a problem hiding this comment.
Yes since this is rejected at execution time, should be safe to remove here.
|
cyclops audit note="focus only on ensuring that the changes in this PR are sound. the base branch is being audited in parallel" |
|
cc @0xrusowsky Cyclops audit event published. View workflow run Config: config: |
👁️ Cyclops Security Review
🧭 Verifying · mode=
Findings
⚙️ Controls
📜 34 events🔍 |
| /// The resulting [`PreparedL1Block`] is ready to be passed through payload | ||
| /// attributes to the builder. | ||
| /// Decrypts encrypted deposits and ABI-encodes into the types the `advanceTempo` call expects. | ||
| /// Mint-recipient policy is enforced by upstream TIP-20 after the L1 state is anchored. |
There was a problem hiding this comment.
Flagging that this now depends on the raw-cache invalidation issue from #698. Once this precheck is removed, encrypted deposits rely on that cache for authorization, so a stale hit can mint where a cold node would bounce.
| 3. **Tempo TIP-20 and TIP-403 precompiles** — execute the upstream business | ||
| logic against that composed storage view, replacing the zone's duplicated | ||
| policy dispatch. Missing or invalid anchored state fails closed, and zone | ||
| logic against that composed storage view, without a separate zone policy |
There was a problem hiding this comment.
Can we clean up the remaining PolicyProvider docs here too? The diagram and note still describe PolicyCache/PolicyResolutionTask, and the payload attrs still say policy checks happen in the engine.
stacked on top of #698
fully drops the
PolicyProvider